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Organisations  that  develop  softivare  for  the  Department  of  Defense  must  have  knowledgeable  people  to  do  the  work  accord¬ 
ing  to  documented  and  mature  processes  and  standards  that  guide  how  the  work  is  accomplished.  The  organisation  must  also 
have  in  place  the  hardware  and  tools  that  are  used  to  execute  the  processes  to  develop  and  test  the  end  products.  Success  of 
their  efforts  depends  on  two  key  elements:  the  fidelity  of  the  test  environment,  and  the  amount  of  collaboration  with  other  agen¬ 
cies  involved  in  their  program. 


The  mission  of  the  76th  Software 
Maintenance  Group  (SMXG,  former¬ 
ly  MAS)  at  the  Oklahoma  City-Air 
Logistics  Center,  Tinker  Air  Force  Base 
(AFB),  Okla.,  includes  positioning  opera¬ 
tional  capabilities  in  the  field,  and  improv¬ 
ing  and  adding  to  them  through  software 
development  and  sustainment.  The  76th 
SMXG  performs  this  mission  for  the  E-3, 
B-l,  B-2,  and  B-52  aircraft,  and  for  the  Air 
Launched  Cruise  Missile  (ALCM), 
Conventional  Air  Launched  Cruise  Missile 
(CALCM),  and  Advanced  Cruise  Missile 
(ACM)  weapons.  The  group  also  has 
extensive  capability  for  development  and 
maintenance  of  Test  Program  Set  hard¬ 
ware  and  software  for  automatic  test 
equipment;  industrial  automation;  and  jet 
engine  testing,  trending,  and  diagnostics. 

Any  organization  that  develops  or  main¬ 
tains  weapon  system  software  must  have 
certain  resources  in  place.  These  resources 
include  people,  a  development  environ¬ 
ment,  a  test  environment,  tools,  and  facilities 
to  house  these  resources.  Policies,  instruc¬ 
tions,  standards,  and  processes  are  required 
to  control  how  the  work  is  accomplished. 
Measurement  and  metrics  requirements 
must  be  established  to  facilitate  tracking 
workload/labor;  to  evaluate  financial  and 
project  performance;  and  to  establish  the 
foundations  for  pricing  future  projects, 
making  management  decisions,  and  process 
improvement  efforts.  We  have  an  outstand¬ 
ing  Software  Engineering  Process  Group 
(SEPG)  that  organizes  and  develops 
processes  and  standards,  and  maintains 
them  online.  It  also  establishes  and  manages 
our  measurement  and  metrics  requirements 
and  process  improvement  efforts  and  the 
organizational  software  quality  program. 

The  76th  SMXG  consists  of  approxi¬ 
mately  500  engineers,  computer  scientists, 
and  staff  personnel,  the  majority  of  whom 
have  in  excess  of  15  years  experience  in  the 
organization.  Various  development  environ¬ 
ments  are  used  based  on  the  weapon  system 
or  automatic  test  equipment  that  the  appli¬ 


cation  software  runs  on,  however,  most 
applications  are  developed  on  IBM  main¬ 
frames,  Sun  workstations,  or  networked  per¬ 
sonal  computers.  Tools  used  include  assem¬ 
blers,  compilers,  and  tools  for  project  plan¬ 
ning  and  management,  labor  tracking, 
requirements  tracking,  configuration  man¬ 
agement,  documentation,  etc.  A  detailed  dis¬ 
cussion  of  all  aspects  of  our  operation  is 
not  possible  within  the  scope  of  this  article, 
and  most  readers  are  aware  of  these  aspects 
from  their  own  experience.  Thus  this  article 
will  focus  on  two  key  areas  that  reduce  risk 
when  fielding  operational  capabilities:  high 
fidelity  test  environments  and  collaboration. 

High  Fidelity  Test  Environments 

The  test  environment  is  one  of  the  key  ele¬ 
ments  in  fielding  capabilities.  If  it  does  not 
emulate  the  fielded  system  to  the  maximum 
extent  possible,  then  the  risk  of  operational 
problems  when  the  software  is  fielded 
increases.  The  initial  Avionics  Integrated 
Support  Facility  Military  Construction 
Project  at  Tinker  AFB  was  built  in  the  early 
1980s  to  provide  floor  space  to  house  the 
software  support  personnel  and  develop¬ 
ment  environments  for  the  E-3,  B-52,  Short 
Range  Attack  Missile  (SRAM),  and  the 
ALCM.  An  example  of  our  high  fidelity  test 
environments,  the  B-52  Avionics  Integrated 
Support  Facility  (AISF),  is  a  hot  mockup  of 
the  aircraft  avionics  interfaced  with  the  con¬ 
trols  and  displays.  Simulated  dynamics  of 
the  aircraft  are  provided  by  a  vehicle  system 
simulator,  and  weapon  simulation  is  provid¬ 
ed  by  a  weapon  system  simulator. 

The  SRAM  and  ALCM  laboratory  area 
was  built  adjacent  to  the  B-52  AISF  area. 
The  cruise  missile  project  provided  inter¬ 
faces  between  the  B-52  AISF  and 
empty/loaded  pylon/launcher  station  as 
well  as  between  the  AISF  and  the  ALCM 
subsystem  simulator.  This  test  environment 
is  used  for  simulation  and  test  of  the  B-52 
operational  flight  software,  the  aircraft  to 
missiles  interfaces,  and  the  missile  opera¬ 
tional  flight  software.  By  utilizing  the  com¬ 


bination  of  the  B-52  AISF  and  pylon  or 
launcher  loaded  with  test  missiles,  all  com¬ 
munication  between  the  aircraft  and  missiles 
can  be  effectively  tested.  The  SRAM  pro¬ 
gram  has  been  disposed  of  and  the  missiles 
laboratory  has  evolved  through  the  years  to 
include  capability  for  ACM  and  CALCM. 

A  missile  electronic  subsystem  simula¬ 
tor,  consisting  of  a  table  of  interfaced  mis¬ 
sile  electronics,  is  also  available.  Breakout 
boxes  can  be  used  at  the  umbilical  connec¬ 
tor,  or  at  any  of  the  internal  missile  interface 
connectors  to  allow  monitoring  of  the  inter¬ 
faces.  Testing  of  the  B-52  operational  flight 
software  and  missile  operational  flight  pro¬ 
gram  is  accomplished  by  first  planning  the 
mission,  then  flying  the  aircraft  mission  on 
the  AISF,  rotating  the  launcher  to  the  prop¬ 
er  missile,  if  necessary,  then  simulating 
launch,  and  finally  simulating  free  flight  of 
the  missile  to  target. 

The  AISF  interface  with  the  ALCM  sub¬ 
system  simulator  is  used  to  test  aircraft/mis¬ 
sile  interface  up  to  launch  and  subsequently 
test  free-flight  simulation  of  the  missile 
operational  flight  program  from  launch  to 
detonation  at  target.  Successful  testing  of  B- 
52  and  missile  operational  flight  software 
and  mission  planning  software  in  this  labo¬ 
ratory  provides  very  high  confidence  that 
flight  testing  will  be  successful  and  that  the 
software  will  provide  the  required  capability 
when  fielded. 

A  government  owned  and  operated  test 
environment  for  weapon  systems  has  bene¬ 
fits  other  than  the  ability  to  fully  test  the 
software.  Having  this  capability  in  a  govern¬ 
ment  facility  allows  it  to  be  used  for  com¬ 
petitive  procurement  of  projects  that  are 
beyond  organic  capability.  For  example,  a  B- 
52  modification  was  programmed  and  fund¬ 
ed,  but  the  sole-source  contractor’s  price  for 
developing  the  modification  at  the  compa¬ 
ny’s  facility  was  in  excess  of  the  budget.  We 
recommended  to  the  program  office  that 
the  project  be  competitively  procured  based 
on  performance  in  our  government  facility. 
The  effort  was  competed,  development  and 
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testing  was  accomplished  in  die  AISF  by  the 
winning  contractor,  and  the  final  cost  was 
approximately  one  half  of  die  original  bid. 

Another  additional  benefit  is  the  expert¬ 
ise  that  organic  personnel  develop  as  a  result 
of  having  this  type  of  laboratory.  An  exam¬ 
ple  of  this  occurred  after  two  B-52/ALCM- 
W80-1  Joint  Test  Assembly  (JTA)  flight 
tests  resulted  in  aborted  launches  with  total 
mission  failure.  An  analysis  of  the  mission 
data  indicated  a  problem  between  the  B-52 
offensive  avionics  system  (OAS)  and  the 
missile  test  payload  (W80-1  JTA).  After 
returning  to  the  home  base,  the  aircraft 
underwent  extensive  ground  testing  by  Air 
Force  personnel  and  no  problem  could  be 
found.  Sandia  National  Laboratories  per¬ 
formed  a  series  of  comprehensive  tests  on 
their  JTA  package  and  concluded  that  it  did 
not  contribute  to  die  aborted  launches. 
Sandia  further  prepared  a  letter  to  the 
Cruise  Missile  Product  Division  detailing 
their  findings  and  recommending  the  Air 
Force  suspend  future  B-52/ALCM  JTA 
flight  tests  until  the  Air  Force  could  identify 
die  source  and  correct  the  problem. 

This  problem  was  referred  to  our  engi¬ 
neers,  and  the  B-52/missiles  laboratories 
were  configured  for  an  ALCM  JTA  launch 
using  missile  and  B-52  production  hardware 
and  operational  software.  Utilizing  state-of- 
the-art  recording  and  analysis  tools,  engi¬ 
neers  performed  multiple  JTA  launches. 
Analysis  of  the  laboratory  flight  test  data 
and  the  JTA  data  from  the  aborted  launches 
clearly  determined  that  die  aborted  launches 
were  a  result  of  the  JTA  package.  Flaving 
determined  die  source  of  die  problem,  engi¬ 
neers  from  the  AISF  presented  dieir  find¬ 
ings  identifying  the  JTA  as  die  source  of  the 
problem  and  isolating  specific  circuits  in  the 
JTA  diat  were  suspect.  Sandia  accepted 
tiiese  findings,  had  additional  testing  per¬ 
formed  on  the  suspected  circuits,  and  was 
able  to  isolate  the  specific  failure  mode. 

Similar  test  environment  capabilities 
exist  in  all  of  our  weapon  system  laborato¬ 
ries.  For  example,  the  E-3  Airborne 
Warning  and  Control  System  (AWACS)  lab¬ 
oratory  has  bodi  surveillance  radar  configu¬ 
rations;  this  way,  all  versions  of  the  E-3  soft¬ 
ware  can  be  tested.  During  Desert 
Shield/Desert  Storm,  an  enhancement  was 
required  to  support  that  effort.  The  require¬ 
ment  was  identified  on  Thursday.  The 
change  was  programmed,  implemented, 
tested  in  die  laboratory,  flight  tested  at 
Tinker  AFB,  and  sent  to  the  theatre  on  a 
resupply  flight  the  next  Monday.  This 
demonstrated  die  fast  turnaround  capabili¬ 
ties  of  organic  resources  widi  high  fidelity 
test  environments. 

This  system  has  also  helped  with  soft¬ 
ware  not  developed  by  our  organization. 


During  die  early  1980s,  die  AWACS  wing 
experienced  a  serious  problem  with  the  E-3 
navigational  computer  system.  The  system 
consistendy  failed  to  capture  the  turn  por¬ 
tion  of  an  established  surveillance  orbit, 
potentially  causing  die  E-3  to  fly  into  unau- 
diorized  airspace.  Serious  consequences 
were  narrowly  avoided  on  several  occasions. 
Once  notified  of  the  problem,  the  E-3  AISF 
was  able  to  reproduce  die  problem  in  the 
laboratory,  locate  the  source  in  anodier 
organization’s  code,  and  develop  a  fix.  The 
modified  operational  flight  program  was 
tiien  tested  in  die  E-3  AISF  and  delivered  to 
die  E-3  fleet  in  a  timely  manner. 

These  types  of  weapons  system  test 
environments  are  normally  established  as  a 
part  of  the  weapon  system  development 
program  at  die  prime  contractor’s  facility. 
The  test  equipment  is  dien  either  duplicated 
at  or  transferred  to  a  government  facility  for 
support  of  the  weapon  system  software 
after  deployment  of  the  weapon  system. 
Since  the  test  environment  includes  the 
avionics  suite,  the  cost  is  very  high.  In  1995, 
replacement  cost  estimates  for  the  AISFs 
were  as  follows: 

•  B  1 :  $171  million. 

•  B-52:  $54  million. 

•  Missiles:  $51  million. 

•  E-3:  $100  million. 

Each  AISF  is  unique  and  may  have  more 
dian  one  hot  mockup  of  die  avionics. 
Simulation  computers  are  typically  Harris 
(now  Concurrent)  computers  and  use 
Fortran,  C,  or  C++,  as  the  source  lan¬ 
guage^)  for  the  simulation  software 
depending  on  die  specific  application.  Our 
experience  is  that  die  high  cost  of  these 
high  fidelity  test  environments  is  well  wordi 
the  investment  because  diey  enable  the  soft¬ 
ware  support  activity  to  provide  die  cus¬ 
tomer  and  the  warfighter  with  die  required 
capabilities  when  diey  are  needed. 

Collaboration 

Another  key  element  in  fielding  capabilities 
is  teamwork  between  the  program  manager, 
system  engineer,  software  developer, 
warfighter,  and  tester.  The  B-52  Mission 
Planning  Software  Section  is  one  of  our  top 
success  stories.  This  section  has  responsibil¬ 
ity  for  development  and  sustainment  of  the 
B-52  mission  planning  software  (B-52 
Aircraft/Weapons/Electronics  [A/W/E]) 
that  runs  on  the  Air  Force  mission  support 
system  (AFMSS).  This  system  essentially 
automates  the  process  that  the  flight  crews 
previously  performed  manually  —  according 
to  the  Technical  Orders  (TOs),  which  are 
used  as  the  basis  for  the  software  require¬ 
ments.  One  of  die  most  important  keys  to 
success  is  customer  involvement.  To  ensure 
diat  the  product  produced  meets  the 


user/customer  requirements,  die  warfight¬ 
ers  are  involved  in  each  phase  throughout 
the  development. 

The  B-52  A/W/E  is  one  element  of  the 
complete  mission  planning  environment, 
which  is  a  combination  of  35  different  ele¬ 
ments  of  software  and  17  pieces  of  dedicat¬ 
ed  B-52  aircraft  software,  as  shown  in  Figure 
1  (see  page  6);  the  Glossary  defines  the 
terms  in  die  figure.  These  are  developed  by 
different  agencies  and  contractors,  and 
many  serve  multiple  weapon  systems. 
Integration  of  all  of  these  applications  on  a 
single  system  to  meet  overall  warfighter 
requirements  is  a  significant  part  of  our 
effort. 

The  main  key  to  success  in  this  area  is 
the  in-depth  understanding  of  die  entire 
environment,  botii  hardware  and  software. 
The  mission  planning  process  is  tested  from 
beginning  to  end,  including  the  production 
of  all  flight  products.  These  products  are 
taken  through  the  final  verification  of  actu¬ 
ally  loading  diem  in  our  B-52  AISF  and  fly¬ 
ing  the  missions,  complete  with  weapons, 
and  the  recording  of  all  the  data  for  analysis. 

Ensuring  success  begins  widi  customer 
or  user  relationships.  More  than  a  tiiird  of 
our  key  people  who  develop  and  maintain 
mission  planning  applications  are  on  a  first- 
name  basis  with  dozens  of  stakeholders: 

•  B-52  System  Program  Office.  All  mis¬ 
sion  planning  system  engineers,  pro¬ 
gram  managers,  and  weapon  system 
integration  engineers  communicate  sev¬ 
eral  times  a  week. 

•  46th  Operations  Group/Test  Squad¬ 
ron.  Responsible  Test  Organization  for 
mission  planning;  participates  in  our 
development  test  (DT),  DT/operational 
test  (OT),  and  formal  qualification  test 

(FQT). 

•  28th  Test  Squadron.  Final  test  audiori- 
ty  for  force  development  evaluation 
(FDE). 

•  Air  Force  Operational  Test  and  Eval¬ 
uation  Center  (AFOTEC)  Detach¬ 
ment  2.  Official  OT  agency  for  mission 
planning. 

•  AFOTEC  Detachment  5.  Official  OT 
agency  for  weapon  systems  like  the 
Cruise  Missiles  and  Joint  Air  to  Surface 
Stand-off  Missile  (JASSM). 

•  49th  Flight  Test  Squadron.  B-52 
Flight  Test  Squadron  at  Barksdale  AFB. 

•  5th  Operational  Support  Squadron. 
Warfighters  from  Minot  AFB. 

•  2nd  Operational  Support  Squadron. 
Warfighters  from  Barksdale  AFB. 

•  Mission  Planning  System  Support 
Facility.  Air  Force  mission  planning 
software  integration,  distribution,  and 
support  from  Hill  AFB. 

As  noted  above,  diroughout  die  applica- 
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Glossary 

A/W/E 

Aircraft/Weapons/Electronics 

FQT 

Formal  Qualification  Test 

ACM 

Advanced  Cruise  Missile 

ICD 

Interface  Control  Document 

AFMSS 

Air  Force  Mission  Support  System 

ICSMS 

Integrated  Conventional  Stores 

AFOTEC 

Air  Force  Operational  Test  and 

Management  System 

Evaluation  Center 

IDD 

Interface  Definition  Document 

AFPD 

Air  Force  Policy  Directive 

INTEL 

Intelligence  Data 

ACM 

Air-to-Ground  Missile 

JASSM 

Joint  Air-to-Surface  Standoff  Missile 

AISF 

Avionics  Integrated  Support  Facility 

JDAM 

Joint  Direct  Attack  Munitions 

ALCM 

Air  Launched  Cruise  Missile 

JSOW 

Joint  Standoff  Weapon 

AMI 

Avionics  Midlife  Improvement 

JTA 

Joint  Test  Assembly 

AWACS 

Airborne  Warning  and  Control  System 

OAS 

Offensive  Avionics  System 

CALCM 

Conventional  Air  Launched  Cruise  Missile 

OT 

Operational  Test 

CALCM  C/D 

Two  versions  of  the  CALCM 

PFPS 

Personal  Flight  Planning  System 

CLOAR 

Common  Low  Observability  Auto  Router 

SRAM 

Short  Range  Attack  Missile 

DAFIF 

Digital  Aeronautical  Flight  Information  File 

SEPG 

Software  Engineering  Process  Group 

DDLC 

Digital  Data  Loader  Cartridge 

SMXG 

Software  Maintenance  Group 

DT 

Development  Test 

SWPS 

Strategic  War  Planning  System 

DTC 

Data  Transfer  Cartridge 

TO 

Technical  Order 

DTUC 

Data  Transfer  Unit  Cartridge 

TBMCS 

Theater  Battle  Management  Core  System 

FDE 

Force  Development  Evaluation 

U2A 

U.S.  Strategic  Command  to  AFMSS 

FPM 

Flight  Performance  Model 

WCMD 

Wind  Corrected  Munitions  Dispenser 

tion’s  life  cycle  the  stakeholders  meet  fre- 
quendy  via  face-to-face  meetings  and  tele¬ 
conferences.  At  least  once  a  year,  a  mission 
planning  open  house  is  conducted  at  the 
user’s  base  of  operations.  This  includes  sev¬ 
eral  days  for  familiarization  with  our  existing 
applications  and  user  interface  working 
group  meetings  to  discuss  upcoming 
designs,  priorities,  trade-offs,  and  require¬ 
ments.  Our  engineers  and  computer  scien¬ 
tists  also  hit  the  road,  spending  an  average 
of  more  than  200  man-days  per  year  in  the 
field,  meeting  with  die  users,  oilier  develop¬ 


ers,  and  other  program  offices  to  continual¬ 
ly  coordinate  efforts,  schedules,  and  require¬ 
ments,  and  to  provide  familiarization  with 
our  systems. 

Requirements  review  boards  for  our 
A/W/E  applications  and  AFMSS  core  are 
conducted  and  defect  review  boards  are 
held  following  each  formal  test.  Eight  offi¬ 
cial  test  events  were  hosted  last  year.  Each 
event  had  one  or  more  users  or  customers 
working  side-by-side  with  the  developers.  As 
part  of  the  development  effort,  several  DTs 
are  hosted  prior  to  the  FQT.  At  least  one  of 


these  DT  tests  will  be  a  combined  DT / OT 
that  is  a  development  test  using  operational 
procedures,  data,  and  crew  members,  mak¬ 
ing  it  as  real-world  as  possible.  This  process 
is  a  profound  strength  in  the  organization. 
Feedback  is  received  from  the  users  contin¬ 
ually  throughout  the  development  phase. 

The  OT  certification  brief  is  prepared 
and  presented.  Using  Air  Force  Manual  63- 
119,  Certification  of  System  Readiness  for 
Dedicated  Operational  Test  and  Evaluation, 
a  matrix  of  33  certification  templates  is  eval¬ 
uated  that  identifies  specific  problem  or  risk 
areas  that  could  hinder  the  smooth  transi¬ 
tion  from  development,  through  test,  to  the 
fielding  of  a  product.  All  of  the  communi¬ 
ties  listed  above  participate  in  this  process, 
and  the  entire  group  agrees  that  the  product 
is  ready  to  be  tested.  This  final  step  provides 
complete  confidence  that  the  products  will 
meet  the  warfighter’s  expectations  the  first 
time,  every  time.  When  a  product  approach¬ 
es  fielding  certification,  the  actual  users  have 
seen  it,  used  it,  evaluated  it,  tested  it,  and 
stand  behind  it  along  with  the  developers. 

A  recent  success  story  centers  around  a 
flight  performance  change  to  the  way  mis¬ 
sion  planners  need  to  account  for  drag  on 
the  B-52  because  of  external  weapons  hang¬ 
ing  on  the  wings.  The  multiple  weapon  con¬ 
figurations  create  different  fuel  burn  rates 
affecting  the  range  of  the  aircraft. 
Implementing  this  change  in  the  TO 
spanned  three  software  releases  and 
required  participation  from  almost  every 
organization  listed  above. 

Through  requirements  review,  software 
development,  integration,  test,  and  the 


Figure  1 :  B-52  Mission  Planning  Environment 
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defect  review  board  process,  each  spiral 
would  furdier  refine  the  requirements,  each 
time  giving  die  user  increased  capabilities 
and  enhancing  the  system  effectiveness  to 
plan  aircraft  missions.  It  became  clear  early 
when  dealing  with  this  issue  that  each  mem¬ 
ber  of  the  team  had  a  different  piece  of  die 
puzzle.  Only  through  continuous  communi¬ 
cation  and  collaboration  were  the  answers  to 
all  the  questions  understood  enough  to  pro¬ 
duce  a  quality  tool  for  die  warfighter. 

From  start  to  finish,  nothing  is  done  in 
a  vacuum  widiout  the  user.  A  lot  of  com¬ 
panies  will  offer  the  user  an  early  look  or 
attendance  at  design  reviews,  but  the  cus¬ 
tomer  seldom  gets  die  complete  picture  or 
real  hands-on  experience  during  develop¬ 
ment  of  its  system.  As  explained  here, 
Tinker  AFB’s  B-52  mission  planning  sec¬ 
tion  goes  above  and  beyond  to  get  the  user 
involved  in  every  step.  Nothing  is  hidden 
or  kept  from  die  customer.  By  involving 
die  users  in  requirements  reviews,  early 
DT  events,  and  using  our  integrated  suite 
of  test  facilities,  die  customer  is  allowed  to 
actually  run  die  system  end-to-end  in  one 
location.  A  demonstration  of  one  or  two 
isolated  pieces  of  the  puzzle  is  not  needed 
because  die  user  sees  the  whole  enterprise 
and  walks  away  widi  a  feeling  of  confi¬ 
dence  that  what  is  paid  for  will  provide  die 
capabilities  required  in  the  field. 

This  type  of  team  effort  is  becoming 
more  important  with  the  Air  Force  Policy 
Directive  (AFPD)  63-1  cited  commander’s 
intent  diat  states,  “The  primary  mission  of 


our  acquisition  system  is  to  rapidly  deliver 
to  the  warfighter  affordable,  sustainable 
capability  diat  meets  dieir  expectations.” 
The  objective  of  AFPD  63-1  is  to  “create 
a  context  diat  allows  the  program  manager 
to  shape  and  execute  a  program  widi  an 
emphasis  on  teamwork,  trust,  common 
sense,  and  agility.”  It  further  states  that 
“the  warfighters,  developers/ acquirers, 
technologists,  testers,  budgeters,  sustainers, 
and  industry  must  plan  and  execute  togedi- 
er  in  order  to  meet  die  Commander’s 
intent.”  These  seem  to  be  lofty  ideals,  but 
we  have  proven  diey  can  be  done. 

Summary 

Fielding  capabilities  can  be  enhanced  by 
having  high  fidelity  test  environments  and 
by  collaboration  between  all  of  the  partic¬ 
ipants  on  a  program.  The  Air  Logistics 
Centers  at  Robins  AFB  and  Hill  AFB  have 
similar  capabilities  to  those  that  are 
described  in  this  article,  although  for  dif¬ 
ferent  weapon  systems.  Program  man¬ 
agers  may  be  able  to  take  advantage  of 
existing  organic  resources  to  reduce  cost 
and  risk.  Furdier,  partnering  agreements 
can  be  established  between  organic  soft¬ 
ware  support  activities  and  contractors  to 
facilitate  utilization  of  organic  resources 
in  teaming  arrangements  to  work  jointly 
on  Department  of  Defense  projects.  All 
diree  Air  Logistic  Center  software  sup¬ 
port  activities  have  Web  sites  (see  page  30) 
diat  provide  contacts.^ 
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